前、後端分離架構 (Frontend-Backend Separation)

前後分離架構將應用程式的前端與後端完全分開，前端負責介面和操作，後端則處理資料邏輯與存取。兩者可透過API進行通訊（通常是REST或GraphQL，可參考 這個文章）。

在前面有說到，單體式架構是將所有的功能與模組組合成單一的應用程式，但套用到網頁上就發現了一個大問題。在早期，許多網站採用的是SSR (Server-Side Rendering 服務端渲染)來組成我們的HTML，也就是說就算套用了MVC模型也只是解決了分工上的問題，漸漸的會發現由於整個應用程式的計算與操作都在主要伺服器上，而使用者這端只會拿到最後產出來的靜態HTML，因此整體應用程式的負擔都會放在伺服器本身，且無法單獨測試每個元件和View的關係。

那到底甚麼是前後端分離呢？剛有說到，在傳統SSR的渲染方式會在伺服器端將資料與模板進行合成送出處理好的HTML，那如果我們可以把模板與部分操作分離，那就一定程度上可以解決伺服器負擔的問題，同時還可以將使用端進行獨立開發，而不影響其他的流程。

所以，到這裡我們大概就知道 所謂的前端是指相對於主要資料處理與判斷的核心伺服器，更貼近於使用者可供顯示/渲染與操作的端點。

前端分離後要放哪？

簡單來說，由於前端模板不在使用者這邊，因此依然也是要有伺服器提供給你，於是我就需要第二台主機？那也不一定，接下來後續文章會提到如何利用雲端解決這個問題。

所以前後端分離的好處是？

由於近幾年專業分工的趨勢越來越高，從原本早期的網站工程師，現在可以簡單分為前端工程師、後端工程師、全端工程師、甚至還有獨立的設計職位負責 使用者介面設計 UI (User interface)、使用者體驗設計 UX（User Experience），如果一個網頁應用程式的設計可以盡可能的進行專業分工勢必能發揮最大功效，舉例來說，我們可以讓美術相關專業的人才進行主視覺設計，並由UX工程師進行相關使用者體驗進行評估、最後由前端工程師進行設計，同時後端工程師也會給出相對應的操作介面使前端可以與後端進行流暢的溝通。

有好總有壞，那缺點是甚麼呢？

在工程上來說，就是團隊協作的問題，當我要加入一個新功能時，不論是前端或後端都有可能需要做調整，有時候可能會使中間的溝通過程變得更加繁瑣、複雜。

我個人認為，與其一直盲目遵從最流行的使用方法，不如一開始就先想清楚該應用適合哪種開發架構，否則只會使你的團隊增加負擔。